Node / meshtastic / Meshtastic-Android / files / RELEASE_PROCESS.md

Displaying Rendered • View raw • Download

This guide summarizes the steps for releasing new versions of Meshtastic Android and Desktop. The process is fully automated via GitHub Actions and Fastlane.

The entire release process is managed by a single, manually-triggered GitHub Action: T383838Create or Promote Release.

• Trigger: To start a new release or promote an existing one, a developer manually runs the workflow from the GitHub Actions tab.

• Inputs: The workflow requires the following inputs:

1. T383838version: The base version number you are releasing (e.g., T3838382.7.0).

2. T383838channel: The release channel you are targeting (T383838internal, T383838closed, T383838open, or T383838production).

3. T383838build_desktop: Whether to build and attach Desktop native installers (default: T383838false).

• Automation: The workflow handles everything automatically:

• Syncs Assets: Fetches the latest firmware/hardware lists, protobuf definitions, and translations (Crowdin).

• Generates Changelog: Creates a clean changelog from commits since the last production release and commits it to the repo.

• Updates Config: Automatically bumps the T383838VERSION_NAME_BASE in T383838config.properties.

• Verifies & Tags: Runs lint checks, builds the app, and only tags the release if successful.

• Deploys Android: Uploads the build to the correct Google Play track and attaches artifacts (T383838.aab/T383838.apk) to a GitHub Release.

• Deploys Desktop (when enabled): Builds native installers (DMG, MSI, EXE, DEB, RPM, AppImage) on a matrix of runners and attaches them to the GitHub Release.

• Changelog: Release notes are auto-generated from PR labels. Ensure PRs are labeled correctly to maintain an accurate changelog.

1. Navigate to the Actions tab in the GitHub repository.

2. Select the T383838Create or Promote Release workflow.

3. Click the "Run workflow" dropdown.

4. Enter the base T383838version (e.g., T3838382.7.0).

5. Select the T383838internal channel.

6. Check T383838build_desktop if you want Desktop installers included in this release.

7. Click "Run workflow".

The workflow will:

1. Create a new commit on the current branch containing updated assets, translations, and the new changelog.

2. Tag that commit with an incremental internal tag (e.g., T383838v2.7.0-internal.1).

3. Build & Deploy the verified Android artifact to the Play Store Internal track.

4. Build Desktop (if enabled) native installers on macOS, Windows, and Linux runners.

5. Publish a draft pre-release on GitHub with all artifacts attached.

Once an internal build has been verified, you can promote it to a wider audience.

1. Run the T383838Create or Promote Release workflow again with the same base T383838version.

2. Select the next channel in the sequence (e.g., T383838closed, then T383838open).

3. The workflow will create a new incremental tag for that channel (e.g., T383838v2.7.0-closed.1) and create a published pre-release on GitHub.

After testing is complete on all pre-release channels, you can create the final public release.

1. Run the T383838Create or Promote Release workflow one last time.

2. Use the same base T383838version.

3. Select the T383838production channel.

4. The workflow will create a clean version tag (e.g., T383838v2.7.0) and create a published, stable (non-prerelease) release on GitHub.

1. Verify Android: Check the Google Play Console to ensure the build is available on the correct track.

2. Verify Desktop (if built): Download and smoke-test at least one installer (DMG, MSI, or AppImage) from the GitHub Release.

3. Merge: Merge the release branch (if one was used for stabilization) back into T383838main.

Desktop native installers are built as part of the main release pipeline when T383838build_desktop is enabled. There is no separate promotion flow for Desktop — installers are built once during the T383838internal release and attached to the GitHub Release alongside Android artifacts.

macOS builds are signed and notarized when the following CI secrets are configured: